If requirements_by_platform is empty (which is common when using uv.lock as the primary source), all_platforms will be an empty list. This results in all packages having empty target_platforms, which will likely cause issues in downstream rules that expect platform information for wheel selection.

Including all provides-extras in the requirement line for every package is likely incorrect. provides-extras lists all extras a package defines, not necessarily what was resolved or requested. Including all of them will force the installation of all optional dependencies for every package in the lock file, leading to significant dependency bloat. It might be better to omit extras from the requirement line if the lock file already provides the specific version and URL, or only include the extras that were part of the resolution.

The logic for collecting extras in the consistency check appears to be flawed. It iterates over the dependencies of pkg and adds the extra name to uv_packages[name]["extras"], where name is the name of the requiring package. Later, when checking a package item, it looks for extras in uv_packages[item.name]["extras"]. This will fail to find extras that were requested by other packages.

Prepending $PWD/ to python_path assumes that the path is relative to the execution root. If python_path is already an absolute path, this will result in an invalid path. It is safer to check if the path is absolute before prepending.

The hash key is optional for wheels in the uv.lock file format. Using direct dictionary access wheel["hash"] will cause a runtime error if the key is missing. You should use .get() for safe access, similar to how it's used for sdist hashes.

Hardcoding $PWD/ for absolute path construction in a shell command might be problematic on some platforms or environments. Consider using ctx.bin_dir.path or similar Bazel-provided paths if possible, or ensure this is only executed in a bash-compatible environment where PWD is guaranteed to be set correctly.

Add a test to ensure this is tested.

Is there just one possible index url?

Yes, only one default, others are extra.

Why does this function have the uv_lock arg as optiona, and fall back to requirements parsing? Its name would indicate it is for parsing uv lock files

Does uv not handle filtering out yanked versions for us?
Though I suppose a version is likely yanked after uv.lock is generated.

What does pypi do if you try to download a yanked version? error or give it to you?

fwiw, i think its fine to make it bzlmod only. I thought the uv.lock rule was already bzlmod only anyways?

This is only to make the loads work easier. The parse_requirements is used in WORKSPACE as well.

When python is configured as an absolute path (e.g., a system interpreter path), python_path will be absolute. Prepending $(pwd)/ to an absolute path results in an invalid path (e.g., /path/to/workspace//usr/bin/python3), which will cause the build action to fail. We should check if python_path is absolute before prepending $(pwd)/.

        python_path = getattr(python, "path", python)
        is_absolute = python_path.startswith("/") or (len(python_path) > 2 and python_path[1] == ":")
        uv_python_path = python_path if is_absolute else "$(pwd)/" + python_path
        command = 'export UV_PYTHON_PATH="{python}" && "$@" --python "$UV_PYTHON_PATH" && cp "{src_dir}/uv.lock" "{output}"'.format(
            python = uv_python_path,
            src_dir = src_dir,
            output = output.path,
        )

Fixed

Setting is_exposed = True for virtual packages (which have no sources, i.e., srcs = []) causes the hub repository to expose them as targets. However, since they have no sources, no corresponding whl_library repository is created for them. This leads to undefined repository errors (e.g., @hub_virtual_pkg not found) when Bazel attempts to resolve or query the hub's targets. We should set is_exposed to len(pkg_srcs) > 0 so that virtual packages without sources are not exposed in the hub.

Update the unit test expectation to match the corrected is_exposed behavior for virtual packages (which should be False since they have no sources).

When out is configured as the standard uv.lock (e.g., out = "uv.lock"), project_dir/uv.lock and out refer to the exact same file path. On Unix systems, attempting to copy a file onto itself via cp will fail with an error (cp: '...' and '...' are the same file). Since set -e is enabled, this will cause the script to terminate with a failure.

To prevent this, we should only perform the copy if the source and destination paths are different.

Similar to the Unix shell script, when out is configured as uv.lock, the copy command on Windows will attempt to copy the file onto itself, which fails with The file cannot be copied onto itself. and returns an exit code of 1.

We should guard the copy operation to only run when the paths are different.

if not "%project_dir%\uv.lock" == "%out%" copy "%project_dir%\uv.lock" "%out%"

Setting target_platforms = list(all_platforms) for all package versions in _parse_uv_lock introduces a correctness bug when a package has multiple versions in uv.lock (e.g., due to different Python versions or environment markers).

Because all versions of the package are assigned the exact same target_platforms, they will all generate the same config settings in _add_whl_library. This causes a conflict during the hub building phase, resulting in a build failure: attempting to override an existing repo '...' for config setting '...' with a new repo '...'.

To fix this, we should parse and evaluate the resolution-markers (or package-level markers) for each package version against the configured platforms to determine the correct subset of target_platforms for each version. If no markers are present, we can default to all_platforms.

In _add_vcs_entry, the VCS URL is extracted solely from source["git"]. However, in uv.lock, git sources typically specify the exact commit/revision in a separate rev (or commit/tag/branch) field (e.g., source = { git = "...", rev = "deadbeef..." }).

If we do not append the revision to the URL, Bazel/pip will not be able to pin the dependency to the correct commit, leading to non-deterministic builds or checkout failures.

We should check if rev is present in source and construct a standard VCS URL format (e.g., git+https://github.com/org/foo.git@deadbeef) which rules_python expects.

Fixed